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ABSTRACT 

Data  modeling  techniques  have  been  used  extensively  in  the 
development  of  an  emerging  standard  for  the  exchange  of  product 
design  and  manufacturing  information.  PDES,  Inc.,  an  industry 
cooperative,  is  applying  resources  to  accelerate  the  development 
and  implementation  of  this  emerging  standard,  the  Product  Data 
Exchange  Specification  (PDES).  An  objective  of  PDES,  Inc.  is  to 
validate  the  completeness  and  usability  of  the  specification. 

This  paper  describes  some  strategic  and  technical  issues  which 
directly  impact  this  effort.  Experience  with  actual  validation 
activities  identified  the  need  to  develop  additional  requirements 
documentation.  This  paper  serves  as  the  background  for  a series 
of  papers  which  will  describe  the  actual  methods  and  processes 
used  in  the  requirements  specification  activity.  Three  types  of 
results  came  out  of  this  requirements  activity.  The  form  of  the 
project  deliverables  changed  considerably.  Insights  on 
conducting  requirements  activities  were  identified.  New  issues 
on  the  relationship  of  this  work  to  portions  of  the  specification 
were  identified. 

Introduction 


The  Product  Data  Exchange  Specification  (PDES)  is  an  emerging 
standard  for  the  exchange  and  integrated  use  of  product 
information  over  the  life-cycle  of  a product  (fig.  1).  This 
specification  will  play  a key  role  in  improving  competitiveness 
and  the  ability  to  manufacture  products  in  a world  market 
[C0088]. 

The  need  for  standardization  has  been  nationally  [HEN88]  and 
internationally  recognized.  Subcommittee  4 of  the  International 
Standards  Organization  (ISO) , Technical  Committee  184  (TC184) , 
passed  a resolution  describing  the  need  for  such  a standard 
(Resolution  1,  ISO  TC184/SC4,  July  1984) ; this  need  has  been 
reaffirmed  on  a number  of  occasions.  The  development  has 
required  enormous  amount  of  technical  effort.  There  have  been 
hundreds  of  contributors  from  a wide  spectrum  of  industry.  The 
national  effort  has  been  coordinated  by  the  IGES/PDES 
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Organization  [SMI89]  and  the  international  effort  has  occurred 
within  Working  Group  1 of  ISO  TC184/SC4.  Both  of  these  standards 
organizations  have  the  common  goal  of  having  a single  standard. 
The  first  working  draft  of  the  specification  has  been  submitted 
to  ISO  TC184/SC4  [SMI88].  It  has  been  registered  with  ISO  as 
Draft  Proposal  10303. 

PDES  differs  from  many  existing  standards  in  that  it  is  not  based 
upon  any  proven  implementation.  The  scope,  complexity, 
divergence  of  approaches,  divergence  of  disciplines,  and 
immediacy  of  need  demand  coordinated  action.  Achieving  a quality 
standard  which  is  useful  across  industry  boundaries  is  of  the 
utmost  concern. 

The  ISO  ballot  on  the  draft  proposal  and  the  United  States  ballot 
response  made  two  facts  evident.  First,  an  enormous  amount  of 
technical  effort  has  been  accomplished.  Second,  the  effort  is 
not  complete  and  the  content  is  untested.  The  ballot  has 
identified  what  areas  need  the  most  effort  as  well  as  many 
specific  deficiencies  with  some  proposed  solutions.  In  this 
respect,  the  ballot  was  positive.  The  ballot  was  the  first 
comprehensive  evaluation  of  the  technical  content,  and  it  is 
helping  to  set  the  priorities  of  the  committees  involved  in  the 
development . 

Another  organization  is  also  working  towards  the  common  goal  of  a 
quality  standard.  PDES,  Inc.  is  a cooperative  of  more  than 
twenty  companies  from  the  aerospace,  automotive,  computer,  ship 
building,  and  other  manufacturing  sectors.  PDES,  Inc.  was  formed 
to  accelerate  the  development,  validation,  standardization,  and 
implementation  of  PDES.  This  organization  has  advantages  over  a 
standards  organization  of  full-time  resources,  a restricted 
scope,  and  a more  controllable  organization.  PDES,  Inc.  has 
government  associates  as  well.  The  National  Institute  of 
Standards  and  Technology  (NIST)  is  one;  NIST's  National  PDES 
Testbed  has  participated  by  providing  testing  facilities,  by 
contributing  to  test  development,  and  through  configuration 
control  of  the  standards  documents  [FUR89].  The  requirements 
effort  described  is  being  conducted  by  PDES,  Inc.  with  NIST 
participation.  All  authors  were  part  of  this  requirements 
activity. 

The  focus  of  this  paper  is  on  providing  a framework  for  PDES, 

Inc.  validation  efforts  and  identify  how  this  affects  the  PDES 
specification.  Data  modeling  has  been  and  continues  to  be  a 
fundamental  technology  used  in  developing  the  specification. 

This  report  is  designed  to  provide  the  foundation  for  a series  of 
papers  which  will  follow  the  process  of  using  the  formal 
description  techniques  for  describing  information  requirements 
and  for  ensuring  that  a model  which  embodies  these  requirements 
is  useful  for  the  purpose  intended.  The  series  will  describe; 
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1)  the  methodologies  used  for  documenting  requirements  and 
developing  information  models; 

2)  the  process  of  developing  information  models; 

3)  a methodology  for  model  validation  and  a description  of 
testing  techniques;  and 

4)  the  development  of  test  criteria,  testing  suites,  test 
procedures  and  such. 

The  series  will  makes  some  important  distinctions  between 
appropriate  validation  techniques  for  models  containing 
information  requirements. 

The  rest  of  the  discussion  in  this  paper  provides  additional 
background  material  that  will  be  needed  to  understand  the  series 
of  papers.  Certain  barriers  to  providing  effective  feedback  and 
acceptable  technical  solutions  to  the  standards  organizations 
have  impacted  the  critical  success  factors  for  this  project. 
Identifying  criteria  to  judge  the  success  of  a project  or 
requirements  activity  is  very  important. 

After  some  experience  was  gained  by  PDES,  Inc.  project  members,  a 
review  occurred  in  the  form  of  a requirements  activity.  A brief 
introduction  to  this  requirements  activity  is  provided,  and  the 
results  are  described  along  with  their  effect  on  the  PDES,  Inc. 
project  as  a whole.  The  findings  changed  the  form  of  the  project 
deliverables  considerably.  Insights  on  conducting  a requirements 
activities  are  identified.  New  issues  on  the  relationship  of 
this  work  to  portions  of  the  specification  were  identified. 
Finally,  the  current  direction  of  the  project  is  provided. 


The  Initial  State 


The  PDES,  Inc.  project  began  its  efforts  with  a collection  of 
conceptual  information  models  and  the  formal  descriptive  language 
models  which  were  developed  by  the  standards  organization.  The 
project  was  divided  into  three  teams.  One  team  focused  on 
improvements  to  these  baseline  models  such  as  completing  the 
documentation.  One  team  concentrated  on  testing  and  validating 
the  models.  The  third  team  was  responsible  for  the  software 
environment  and  prototype  implementations. 

The  decision  was  made  in  the  first  phase  of  the  project  to  limit 
the  scope  to  mechanical  piece  parts  and  rigid  body  assemblies. 

In  addition,  this  initial  phase  was  only  concerned  with  PDES  used 
for  exchange  purposes  and  not  for  the  integrated  sharing  of 
product  data  between  processes.  The  modeling  team  identified  the 
subset  of  models  needed  for  this  purpose.  This  team  studied, 
evaluated  the  quality  of  the  modeling,  and  corrected 
deficiencies.  The  validation  team  developed  a model  validation 
methodology  which  was  adapted  from  accepted  software  testing 
methodologies  [HET88].  The  implementation  team  concentrated  on 
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putting  together  a prototyping  environment.  Some  months  of  work 
took  place,  and  reworked  models  were  released  as  feedback  to  the 
standards  organization.  There  were  difficulties  associated  with 
completing  the  models  and  testing  them.  A limited  number  of 
these  problems  have  more  general  relevance  to  data  modeling 
projects,  and  these  deserve  discussion. 


Barriers  to  Making  it  Work 

The  barriers  to  providing  effective  feedback  and  technical 
solutions  that  are  accepted  by  the  standards  organization  really 
fall  into  two  categories:  those  which  are  related  to  PDES 
strategic  issues  and  those  which  are  technical  issues.  The 
strategic  category  includes  scoping  issues  and  the  standard- 
making process.  The  technical  concerns  involve  the  use  of 
multiple  data  modeling  methodologies,  the  lack  of  proven 
techniques  for  validating  conceptual  models,  and  the  lack  of 
software  tools  that  work  together  to  aid  in  the  development  and 
testing. 

The  scope  of  PDES  is  enormous.  PDES  is  envisioned  to  support  all 
aspects  of  product  description  from  initial  conception  through 
product  design,  manufacture,  support  and  disposal.  In  addition 
to  this,  PDES  is  intended  to  support  a broad  industrial  base. 
There  is  an  analogy  between  this  effort  and  any  enterprise  which 
attempts  to  get  its  information  requirements  under  control.  Any 
project  which  is  accountable  must  restrict  the  scope  of  its 
efforts  to  something  which  is  both  useful  and  realistically 
accomplishable  within  the  allowed  schedule  and  resources.  The 
challenge  to  the  PDES,  Inc.  project  has  been  to  carve  out  a 
useful  subset  of  the  entire  PDES  effort,  and  at  the  same  time  to 
ensure  that  the  piece  will  fit  into  the  larger  scheme.  The 
challenge  to  the  first  data  modeling  project  for  an  enterprise  is 
to  build  a framework  for  information  requirements  and  then  to 
scope  follow-on  efforts  into  useful  and  manageable  pieces. 

The  standards-making  bodies  must  achieve  a consensus  on  technical 
content  before  a standard  can  be  achieved.  Alternative  technical 
solutions  must  be  weighed,  and  one  solution  must  be  agreed  upon. 
This  consensus-building  process  can  be  difficult  and  lengthy.  It 
is  appropriate  for  each  member  of  such  an  activity  to  have  their 
own  company's  best  interests  in  mind.  A standards  organization 
has  no  control  over  the  available  manpower  or  the  skills  that 
these  resources  have.  Neither  contract  nor  employment  bind 
members  to  work  commitments.  The  standards  organization 
management  must  always  rely  upon  the  good  will  of  corporate 
management  to  support  their  member  contributions.  A shortage  of 
team  skills,  data  modeling  skills  and  technical  publications 
skills  have  had  a negative  impact  on  the  PDES  development  effort 
[DAY88] . 
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The  need  to  recognize  that  multiple  agendas  will  exist,  the  need 
to  obtain  committed  resources,  and  the  need  to  have  the  correct 
balance  of  skills  available  are  all  project-planning  issues. 

These  issues  were  addressed  by  the  PDES,  Inc.  requirements 
project,  and  they  are  relevant  to  other  requirements  projects  and 
data  modeling  activities. 

The  technical  issues  are  not  any  easier  to  solve.  One  technical 
issue  has  been  the  data  modeling  techniques.  In  developing  PDES, 
a number  of  data  modeling  approaches  have  been  used.  EXPRESS  is 
formal  descriptive  language  for  data  definition.  EXPRESS  was 
chosen  for  writing  the  normative  specification  forwarded  to  ISO 
TC184  SC4 . IDEFIX  is  a graphical  semantic  data  modeling 
technique.  An  informational  annex  to  the  specification  used 
IDEFIX.  IDEFIX  and  other  data  modeling  techniques  were  used  to 
develop  the  information  content  embodied  in  the  specification. 
Each  committee  within  the  IGES/PDES  Organization  chose  the 
technique  or  techniques  they  found  most  appropriate  [BUR89] 
although  there  were  attempts  to  restrict  their  work  to  either 
IDEFIX,  EXPRESS  or  both.  Only  IDEF  and  EXPRESS  are  being  used  in 
the  PDES,  Inc.  efforts. 

No  proven  translation  utilities  exist  between  IDEFIX  and  EXPRESS. 
There  is  no  direct  correspondence  between  all  concepts,  although 
a correspondence  can  be  derived  for  a majority  of  concepts. 

While  EXPRESS  definitions  can  convey  more  concrete  implementation 
decisions  and  more  formalized  constraints,  the  semantics  of 
information  should  be  compatible  between  the  IDEFIX  and  the 
EXPRESS  forms.  The  compatibility  of  semantic  content  is  one  key 
issue  in  validating  the  specification. 

Another  technical  issue  is  related  to  the  best  approaches  for 
testing  conceptual  information  models.  The  initial  months  of 
experience  with  the  software  testing-based  techniques  led  some 
project  members  to  question  whether  there  were  better  methods  for 
verifying  the  quality  and  usefulness  of  these  resources.  The 
criteria  found  in  the  specification  was  either  extremely  high- 
level,  such  as  design  goals,  or  explicitly  stated  within  the 
model  to  be  tested.  Many  criteria  that  the  testing  team  could 
derive  readily  were  subjective,  and  there  were  questions  of 
whether  the  criteria  could  address  usefulness  and  usability 
issues.  One  sample  question  relates  to  the  Geometry  Model  [sub- 
clause 4.3],  is  it  meaningful  to  test  the  model's  elements  when 
they  are  only  used  when  collected  together  with  elements  from 
other  models?  A test  criteria  task  group  was  formed  to  analyze 

the  techniques  in  use  and  to  refine  these  techniques  to  make  them 

more  appropriate  for  testing  information  models. 

The  desired  environment  for  developing  complex  formal 
specifications  would  include  software  tools  that  would  both  aid 
in  the  development  and  participate  in  the  validation  of  the 

specification.  Fragments  exist  which  should  be  part  of  this 
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environment,  but  there  is  nothing  which  comes  close  to  a 
comprehensive  toolset  for  PDES.  Such  tools  could  play  an 
important  role  in  the  fitness  testing  of  information  models.  The 
testing  tool  set  should  include  modules  to  check  the  syntax,  to 
check  the  semantic  consistency,  to  provide  for  constraint 
checking  libraries,  to  support  the  convenient  capture  of  test 
results,  and  to  support  a simulation  environment.  Many  questions 
related  to  semantics,  usefulness,  and  compatibility  between 
IDEFIX  models  and  EXPRESS  specifications  can  only  be  answered  by 
either  simulation  or  actual  implementation.  Simulation 
techniques  have  promise  and  other  standards  efforts  using  formal 
descriptive  techniques  have  found  building  a simulation 
environment  to  be  essential  [SIJ89]. 


Where  the  Effort  Is 


Management  of  the  PDES,  Inc.  project  chose  to  study  the  concerns 
raised  during  the  initial  months  of  experience  by  bringing 
together  a small  task-group.  The  most  pressing  concerns  rested 
within  the  domain  of  testing  and  validation.  The  testing  tasks 
were  openly  accepted  as  the  most  difficult  to  accomplish.  The 
top  priorities  were  to: 

Develop  a testing  approach  that  could  evaluate  "usefulness" 
by  defining  an  applications  framework  for  PDES. 

Develop  criteria  for  the  selection  of  targeted  applications. 
Develop  plans  and  justifications  for  follow-on  activities. 

The  findings  of  this  effort  set  the  direction  for  the  current 
efforts  of  the  entire  project. 


Impact  on  the  PDES»  Inc.  Project 

The  recommendations  identified  by  the  PDES,  Inc.  testing  criteria 
task  group  have  resulted  in  key  refinements  to  the  interactions 
between  the  teams.  Modeling  efforts  are  now  focused  on  building 
context-driven  integrated  models  (CDIMs)  which  focus  on  the 
information  requirements  of  specific  applications  and  identify 
how  to  apply  the  more  general  resources  found  in  the  topical 
models.  Testing  efforts  are  now  focused  on  deriving  acceptance 
criteria  based  upon  what  is  useful  to  specific  applications  and 
are  restricted  to  the  use  of  PDES  for  exchange  purposes.  The 
implementation  team  now  has  much  more  specific  requirements  and 
priorities  for  the  tools  needed  for  model  development  and  model 
testing. 
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Lessons  for  Recruirements  Activities 


The  task  team  developed  a set  of  lessons  learned  from  their 
experience  for  the  follow-on  activities.  We  believe  that  some  of 
them  have  a more  general  application  to  activities  beyond  what  we 
are  currently  tasked  to  accomplish.  These  are: 

Any  project  needs  to  gain  peer  and  management  support. 
Activities  which  will  accomplish  this  need  to  be  planned  and 
scheduled  periodically  during  the  activity. 

A team  will  naturally  have  diverse  skills,  personalities, 
and  agendas.  The  diversity  is  beneficial  if  individual 
skills  are  identified  at  the  beginning  and  continuing  team 
duties  are  assigned  based  on  these  skills  soon  after  the 
activity  begins.  Everyone  on  the  team  needs  to  be 
responsible  for  tasks  that  they  can  successfully  perform. 

The  structured  methodology  provided  us  with  an  operational 
framework  that  was  valuable  in  keeping  us  focused  and  making 
efficient  use  of  time.  The  specifics  of  this  will  be 
discussed  in  a paper  that  follows. 

The  team  effort  really  did  produce  better  results.  We  had 
good  expertise  and  experience  on  the  team.  Still,  even  the 
best  individual  contribution  was  weak  when  compared  to  a 
team  collaborative  effort. 

Having  a support  team  was  CRITICAL  to  the  success.  The 
greatest  impact  came  from  those  who  participated  in  a review 
capacity.  Even  the  most  brilliant  idea  needs  a sanity 
check.  These  reviews  kept  us  on  track,  added  value,  and 
accelerated  our  progress. 

Other  support  team  members  allowed  us  to  keep  focused  on  our 
work  by  making  sure  the  facilities  and  supplies  we  needed 
were  available. 


Additional  Issues  Identified 


The  testing  requirements  task  group  was  able  to  identify 
additional  issues  relating  to  the  validation  of  CDIMs  and  the 
specification.  These  issues  could  not  be  resolved  within  the 
scope  of  the  activity.  They  remain  as  issues  which  must  be 
resolved  within  the  follow-on  PDES,  Inc.  activities  and  through 
PDES,  Inc.  coordination  with  the  standards  organization. 

The  first  issue  which  needs  resolution  is  the  effect  of  CDIM 
validation  on  the  topical  models  and  other  work  from  the 
standards  organization.  Validating  a CDIM  only  validates  the 
portions  of  models  that  were  needed  by  the  application.  A CDIM 
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is  validated  only  for  the  specific  usages  within  the  application 
context.  The  implication  is  that  validation  needs  to  occur  for  a 
variety  of  usages  before  there  is  a degree  of  confidence  that  the 
topical  models  in  the  specification  are  suitable  for  the  variety 
of  disciplines  the  specification  is  targeted  to  support. 

The  next  issue  relates  to  what  information  should  be  in  the 
general  requirements  found  currently  in  topical  models.  It  is 
likely  that  additional  information  requirements  will  be 
identified  for  the  application  usages.  The  unanswered  question 
is  by  what  criteria  should  these  requirements  be  evaluated  to 
determine  if  any  should  be  added  to  the  resource  pools  of  topical 
models . 

The  last  issue  is  that  the  review  of  CDIM  development  and  testing 
approach  identified  a relationship  to  work  going  on  in  the 
Application  Validation  Methodology  Committee  of  the  IGES/PDES 
Organization.  Their  application  protocol  (AP)  work  has  similar 
concepts  [HAR89].  The  AP  methodology  has  only  recently  been 
adopted  for  PDES,  although  the  AP  methodology  is  being  tested  in 
the  IGES  environment.  This  methodology  requires  further 
refinement  in  order  to  ensure  its  utility  for  PDES.  We  feel  that 
the  CDIM  development  and  testing  should  precede  the  development 
of  standardized  application  protocols. 

Current  Direction 


There  are  four  follow-on  activities  taking  place.  Two  are 
developing  CDIMs  and  two  are  developing  testing  criteria  for 
CDIMs.  This  work  will  take  three  months  to  complete. 


Terminology  Defined 

The  following  terms  can  be  expected  to  be  used  throughout  the 
series  of  papers: 

Application  Protocol  (AP)  - A method  to  achieve 
consistent  and  reliable  exchange  of  product  definition 
data  within  a specified  application  area.  The  key 
components  of  an  application  protocol  are  a conceptual 
information  model  for  the  application  area  with 
supporting  documentation,  an  application  protocol 
format  specification,  and  a set  of  application  protocol 
test  cases.  [HAR89] 

Assertions  - A logical  expression  specifying  a state 
that  must  exist  and/or  a set  of  conditions  that  a 
process  interface  must  satisfy  at  a particular  point 
during  process  execution.  [IS089-1] 
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Conceptual  Information  Model  - A description  of  the 
information  requirements,  relationships  between 
informational  objects,  information  structure,  and 
constraints  for  a subject  area. 

Conformance  Testing  - The  testing  of  a candidate 
product  for  the  existence  of  specific  characteristics 
required  by  a standard.  Testing  the  extent  to  which  an 
implementation  under  test  is  a conforming 
implementation.  [OSI88] 

Context  Driven  Integrated  Model  (CDIM)  - A conceptual 
information  model  which  represents  the  information 
requirements  of  a discipline  or  application  usage.  The 
model  is  integrated  because  it  draws  upon  the  resources 
of  other  models  to  specify  shared  information 
requirements  and  is  not  specific  to  an  application. 

Expected  Result  - A foreseen  test  outcome  converted  to 
the  required  form  for  analysis.  [IS089-1] 

Fitness  Test  - The  review  and  walk-through  of  an 
application  reference  model  which  demonstrates  that  the 
model  is  useful  in  a particular  application  area. 
[IS089-1] 

Integrated  Model  - A conceptual  information  model 
which  represents  the  assemblage  of  multiple  information 
models  into  a coherent,  non-redundant , and  internally 
consistent  model.  An  integrated  model  is  characterized 
by  an  even  degree  of  detail  and  elements  which  are  at 
the  same  level  of  abstraction. 

Integrity  Testing  - Those  tests  applied  which 
demonstrate  that  an  application  reference  model  is 
syntactically  correct  and  self-consistent.  [IS089-1] 

Semantics  - (1)  The  meaning  that  is  assigned  to  an  item 
of  information.  [HAR89]  (2)  The  discipline  of 
expressing  the  meanings  of  computer  language  constructs 
in  metalanguages.  [ANS83] 

Topical  Model  - A conceptual  information  model  which 
represents  the  set  of  information  requirements  needed 
to  represent  a subject  matter.  A topical  model  is 
intended  to  be  a shared  resource  and  therefore  is  not 
expected  to  contain  concepts  specific  to  any  particular 
application  or  industry. 

Verification  - The  process  of  determining  whether  or 
not  the  products  of  a given  phase  of  the  development 
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cycle  fulfill  the  requirements  established  during  the 
previous  phase.  [IEEE84] 

VizUsility  Testing  - The  process  of  fitness  testing  and 
integrity  testing.  [IS089-1] 
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